I've read the DOORS DXL documentation and also some forum topics about TCP/IP connection, but the concrete behavior of the different recv() functions is not completely clear to me.
My current assumption/observation is that (on the server side) recv(IPC, Buffer) is a non-blocking call, that is, it checks if data to read is available. If data is available it writes it to the buffer and returns true. If no data is available (or socket is closed?) it returns false. recv(IPC, Buffer, int n) is a blocking call, that is, if data is available it writes it to the buffer and immediately returns true, and if no data is available it waits for at least n seconds to receive any data. So it returns as soon as at least one byte is available? What happens when the client closes the socket? I also see that for each recv(IPC, Buffer) call at most 254 bytes are written to the buffer. Is this size predefined internally?
I want to implement a server in DOORS. The client (Java) will be run on another computer.
Best regards, UweR - Tue Feb 16 07:57:44 EST 2016 |
Re: Behavior of recv() function Question for you. If you are going to use DOORS as a server, why would you want to use the recv() function. |
Re: Behavior of recv() function DOORSHAM - Wed Feb 17 15:49:23 EST 2016 Question for you. If you are going to use DOORS as a server, why would you want to use the recv() function. The use case is that the DOORS client and the Java program will run on different machines. To communicate with each other, the DOORS client should run a DXL script, which opens a TCP/IP server and receives commands from the Java client. So I do not want to communicate directly with the DOORS server. |
Re: Behavior of recv() function UweR - Thu Feb 18 07:15:45 EST 2016 The use case is that the DOORS client and the Java program will run on different machines. To communicate with each other, the DOORS client should run a DXL script, which opens a TCP/IP server and receives commands from the Java client. So I do not want to communicate directly with the DOORS server. Perhaps you could review what you are calling a DOORS Server, doesn't it sound like you are using DOORS as the client. If you are planning to use DOORS as both the client and a server -- you might find yourself going down a rabbit hole, quickly |
Re: Behavior of recv() function Sorry If I do not answer your questions directly ... I have implemented a DXL DOORS Server and I had a lot of issues with blocking. When you write that recv on a server socket does not block it would make absolute sense, but I never tried it and its easy enough to find out for yourself. Still I think, that when you implement a server in DXL, you should make a protocol that will prevent blocking by always knowing beforehand how much data to read. I made one in this project: https://github.com/domoran/DriveDOORS But I don't consider it state of the art. As an alternative approach I would suggest, you implement the Server Component in Java. From the Java Server you launch DOORS Batch Jobs. Another simply alternative to using IPC sockets is to use a simple file based communication. So the Java Server can take the commands from the network and write code to execute to a file. A running DXL instance can detect the presence of the file, read the data and execute the script without the possibility of blocking. Hope that helps, regars, Mathias |